Date: Sat,  9 Jan 93 04:30:14 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #9
To: tcp-group-digest


TCP-Group Digest            Sat,  9 Jan 93       Volume 93 : Issue    9

Today's Topics:
                            8086 compiles
                      CPU ID test code (2 msgs)
                          DPMI mode (2 msgs)
                     MID dups problem - Revisited
                              NNTP usage
                           NOS under Minix
                      PMNOS 1D NOT AT CHOWDANET
                             PMNOS V1.0D
                         Thanks. info wampes
                              TNOS info
                            Unwanted mail
                            update TCPCMD
                             V40 machine
                           WHAT IS SMACK ?
                       WNOS-Group server Back.
                                xspawn
                          XSPAWN - once more

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 8 Jan 93 10:40:42 MST
From: Larsen Karl VAL-C 678-3145 <klarsen@wsmr-emh73.army.mil>
Subject: 8086 compiles
To: tcp-group@ucsd.edu

 Before there is any problem, I have an 8086 lap-top that I run
nos in so I at least will need a copy of nos that is compiled for that
cpu. So I will do this: As I get the source codes for the latest
versions of nos I will compile an 8086 version and place it on UCSD and
tomcat. 

 If I have a problem I will yell here for support.

73, karl k5di@k5di.nm.usa.na

------------------------------

Date: Fri, 8 Jan 93 19:21:36 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: CPU ID test code
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)

> Date:    Thu, 7 Jan 1993 16:55:07 -0500 (EST)
> Message-Id: <930107165507.3ec7@ids.net>
>
> The main objective for my CPU test program right now is so obvious that
> you didn't think of it!  If there is going to be a 386-specific version
> on NOS, it has to at least produce and intelligible error message if
> someone tries to run it on an XT or 80286.  This is a user support issue.
> If the program isn't smart enough to quit gracefully on a machine that
> can't run it, it will most likely just lock up.

Right (however I know about commercial product (operating system),
dedicated for 80386 which didn't have CPU type check in it).

But probably it cannot be coded into C program: to test it I compiled
CPU test program (just your program translated to C I sent to tcp-group)
with -2 option (I have BC 3.0 only, it doesn't have -3 option) and tried
to run (using machine code debugger, of course) - and I found first
opcode of main() is ENTER, which is not valid 8088 opcode and would
cause crash if executed. Can write main() in assembly (code to verify
CPU followed by JMP C_main or so), but we cannot be absolutely sure
library routines executed before main() use valid 8088 opcodes only
(trying to run my program I had a little hope the startup code of .EXE
made with -2 option checks on what CPU it runs).

Other ways: modify .EXE to put extra startup code in it (similar way
many viruses do it: append new code on end, put old transfer address
in the new code, change module size and transfer address in header;
it requires the .EXE to contain no overlays);
or link extra startup code (this needs put name of startup routine
in the code added, need know it and may be compiler-dependent; this
also causes the CPU check code to remain in memory all time).

> It would be nice if my CPU test program eventually can be used to run
> one version of NOS which will automatically select 386 or generic
> instructions, but the performance penalty would probably be too high

Performance loss is during loading the program only: need select what
is to be loaded. But this means either 2 copies of program to be on
disk (one for 8088, second for better CPU) or the loading program must
be smart enough to select what parts are to be loaded (this would need
something like diff, but for executable files, to prepare data for it;
a lot of work and don't know if can get any positive effect; note to
build executable need compile all modules for both modes, for what
reason, I suppose no one is changing CPU in his computer every day).
First concept is more sensible: a program can be named NOS.COM, it
should check what CPU it runs on, say it is 286, then is searches the
directory it was loaded from, say it founds NOS.EX3 (for 80386) and
NOS.EX1 (for 80188 or better), it should say no NOS.EX2 was found
(for user to know what is best for his computer) and load NOS.EX1.
This (or program setting exit code dependent on CPU + batch using the
code to select proper command) can be good for LAN where most programs
are on network disks and there are different machines using them.
And it doesn't require to modify anything in NOS sources.

73's, JT

------------------------------

Date: Fri, 8 Jan 1993 16:04:08 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: CPU ID test code
To: tcp-group@ucsd.edu

From: IDS::MIKEBW       "Mike Bilow, <mikebw@ids.net>"  8-JAN-1993 15:53:32.36
To: SMTP%"JT@zfja-gate.fuw.edu.pl"
CC: MIKEBW
Subj: Re: CPU ID test code

I didn't realize that BC++ would put an ENTER instruction at the beginning
of main() if the "-3" compiler switch was used.  That's a problem.  I will
look into the c0.asm module that comes with BC++; it may be possible to
use a reserved name for my CPU test routine and have it executed before
main().  Modifying c0.asm is not something I would want to do, although
it would obviously fix this problem.

Another thought I had was to wrap NET.EXE inside a small loader which
tested the CPU and then transferred control to the program wrapped
inside.  PKLITE, for example, works this way, and it is a lot more
complicated.

It seems to me that it would have been a good idea for Borland to have
included the CPU trap as a part of the "-3" switch.  It would be a nice
feature as well with the "-2" switch.

-- Mike Bilow, <mikebw@ids.net>  (Internet)

------------------------------

Date: Fri, 8 Jan 93 10:13:09 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: DPMI mode
To: tcp-group@ucsd.edu

Bruce Perens writes -
        well, alot of good stuff abt linix (Unix lite).
Oh, dare I start....
Everything he said abt the pluses of Linix are also true for OS/2.
The really good new is that the negatives he mentioned are not true
for OS/2, ie:
 No step learning curve since its cmd structure is almost identical to DOS
 OS/2 does run existing DOS applications
 OS/2 does run 99.999% of existing Windows applications.

NOS for OS/2 does exist, the GNU compiler is free etc.
Well enough of my soap boxing, I simply couldnt resist. Walt

------------------------------

Date: Fri, 8 Jan 1993 10:50:56 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: DPMI mode
To: kz1f@legent.com

I guess the point I should be making is that those of us with 386 and
higher class processors should be running more modern operating systems
than DOS. Pre-emptive multiprocessing and protected virtual address
spaces have been around for three decades. Programming multiple-client
systems without them is possible, but perhaps more hassle than it is
worth. 

I agree, OS/2 is a fine platform, and runs DOS and Windows applications,
even those that do direct screen write. If you want to run DOS or
Windows applications on the same system with NOS, OS/2 is your best
platform today. Being a kernel hacker, I prefer a system where I can have
the kernel source, but a supported commercial system is a better idea
for most non-hackers.
     Bruce Perens

On Fri, 8 Jan 1993 kz1f@RELAY.WESTBORO.LEGENT.COM wrote: 

> Bruce Perens writes -
>         well, alot of good stuff abt linix (Unix lite).
> Oh, dare I start....
> Everything he said abt the pluses of Linix are also true for OS/2.
> The really good new is that the negatives he mentioned are not true
> for OS/2, ie:
>  No step learning curve since its cmd structure is almost identical to DOS
>  OS/2 does run existing DOS applications
>  OS/2 does run 99.999% of existing Windows applications.
> 
> NOS for OS/2 does exist, the GNU compiler is free etc.
> Well enough of my soap boxing, I simply couldnt resist. Walt
> 
> 
> 

------------------------------

Date: Fri, 8 Jan 93 19:24:40 PST
From: Bill Healy <healy@moriah.ee.unr.edu>
Subject: MID dups problem - Revisited
To: tcp-group@ucsd.edu (tcp-group)

> Well, with a simple addition to the forward.c file of WG7J1.07b, the dup
> MIDs problem is history! This is the snip of code I added to TNOS to
> handle the problem. I've sent it to Johan, and he is adding it to JNOS.
> The code changes the bid from $abcde_host.domain to $abcde%destinationuser.

What is abcde, the message number?

Bill N8KHN

------------------------------

Date: Fri, 08 Jan 1993 09:58:09 CST
From: ben@val.val.com (Ben Thornton)
Subject: NNTP usage
To: tcpgroup@ucsd.edu (TCP/IP Packet Radio Working Group)

Does anyone have any experiences using the NNTPS features of JNOS1.07?

One of the local IP stations and I decided to set up one of his machines
as an NNTP server and we began posting test articles from my machine via
radio link and from his machine via a SLIP connection.  What happened was
that when I posted some articles on my machine and then kicked my NNTP
client (I did it gently :-), it forwarded the articles to the server just fine,
but when the other fellow kicked his client on his second machine, no new
articles showed up on his local disk.  Am I missing something (other than the
documentation)?

  Ben


--
Ben Thornton             packet:  wd5hls@wd5hls.ampr.org
Video Associates Labs  Internet:  ben@val.com
Austin, TX                 uucp:  ...!cs.utexas.edu!val!ben
"Push to Test --->@    ...Release to Detonate"

------------------------------

Date: Fri, 08 Jan 1993 14:02:01 est
From: "Clayton Decosterd" <clay@drone.hazeltine.com>
Subject: NOS under Minix
To: tcp-group@ucsd.edu

Hi All,
 
  I have a copy of the Minix operating system for the PC. I would like 
to know if anyone is running NOS with this operating system. Any
info would be appreciated. 

Thanks 
  73
Clay KB2FUR

-- 
Clayton DeCosterd      INTERNET  : clay @ drone.hazeltine.com
                       COMPUSERVE: 71754,447

------------------------------

Date: Fri, 8 Jan 1993 16:25:33 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: PMNOS 1D NOT AT CHOWDANET
To: kz1f@legent.com, tcp-group@ucsd.edu

Walt's uploads of the new PMNOS 1D were trashed by the virus scanner at
ChowdaNet.  By using the GNU ZIP tools, Walt would have created a slightly
incompatible archive file.  In particular, GNU ZIP uses the new "deflate"
compression algorithm that is in PKZIP only as of the beta versions.  The
official version of DOS PKZIP that is used by the ChowdaNet virus scanner
apparently didn't know what to do, reported an error code, and the files
were treated like a corrupt ZIP file and trashed.

I can straighten this out, since I can bypass the virus scanner using
sysop privleges.  (Walt could have bypassed the virus scanner himself
just by using an extension other than "ZIP," but he didn't know.  Of
course, any file named like that is handled manually by the susop.)

Until I can fix this when I have time to push 1.5 MB back and forth
later tonight, DO NOT CALL CHOWDANET for PMNOS.  If all goes well, I
should have things right by Saturday morning.

-- Mike Bilow, <mikebw@ids.net>  (Internet)

------------------------------

Date: Fri, 8 Jan 93 10:53:51 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: PMNOS V1.0D
To: tcp-group@ucsd.edu

It is with great pride/relief that I am announcing the general availability of 
PM NOS V1.0D. As I have mentioned earlier this most probably will be it for 
PMNOS as you have all come to know it. Technology hasnt stopped and neither 
have I. My next offerring, to be named later, will be based on an entirely 
different technology, support SCC and i-net. Enough on futures. Through next 
fri, PMNOS1DX (executable, intronos.inf and assorted readmes) as well as 
PMNOS1DS (source) will be available via anonymous ftp from giskard.uthscsa.edu.
After next fri these files will be availible at ucsd.edu. A couple of notes:
You will need a recent (1.2 or 2.0) pkunzip or preferable the OS/2 32 bit GNU 
unzip to unzip thes files. If you dont have this gem, its available at hobbes 
and also probably watson.
PMNOS now remembers, should you want it to forget, delete nos.ini from your 
selected spool dir.
The PMNOS1D? pair is also available from ChowdaNet (401)331-0304.
Have fun, enjoy and BE SURE to read the readme.now file.
Walt

------------------------------

Date: Fri, 08 Jan 93 16:22:16 CET
From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
Subject: Thanks. info wampes
To: TCP-GROUP <TCP-GROUP@ucsd.edu>,

Thanks for the tip on wampes will look at the linux code later.
Thanks. Barry

------------------------------

Date: 08 Jan 1993 12:19:32 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: TNOS info
To: tcp-group@ucsd.edu

Well, TNOS is not out yet, but it's not far away! A couple of quick code
fixes and I'll be on to "minimal" documentation.

Several of you expressed interest in helping distribute the source/exe to
several different locations. Thanks! If you can assist in getting it to the
"masses", please send me a RF packet message (not Internet, please) in the
following manner....

   To: REQSVR@KO4KS.#TPA.FL.USA.NA
 Subj: Group Subscribe TNDIST

This will help me, by allowing my TNOS board to automate the mailing-list.

Also, I will be posting a "What else is in TNOS" message soon!

 
73 from Brian A. Lantz      KO4KS@KO4KS.#TPAFL.FL.USA.NA    3100813105
                  Internet: brianlantz@delphi.com
                   Amprnet: ko4ks@ko4ks.ampr.org         [44.98.0.167]

------------------------------

Date: Fri, 8 Jan 1993 18:42:27 -0100 (GMT-1:00)
From: andy@mimuw.edu.pl (Andrzej K. Brandt)
Subject: Unwanted mail
To: tcp-group@ucsd.edu

Hello there,

There is one thing in NOS that I really don't like and I wonder if there is any
way to change that. It's the fact, that NOS accepts all mail addressed to host.
I don't see any way to make him refuse mail to some "users" as grown up
Internet hosts do.

The problem is, that I use address andy@sp5wca.ampr.org on 44-net, but others
insist on mailing to sp5wca@sp5wca. This is not a big problem, it's just
annoying. I dream about such a guy getting a nice <User uknown> returned
letter. But it becomes more serious when we connect NOS to real Internet and
someone makes an error in addressing, or for example replays to a public PC,
from which many people send their mail via SMTP but only few receive it.

So - is there any possibility of changing that?

-- 


                               73 de Andy SP5WCA


/-------------------+--------+-------------------+-------------------------\
I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I sp5wca@sp5pbe.wa.pol.eu I 
\-------------------+--------+-------------------+-------------------------/

------------------------------

Date: Fri, 8 Jan 93 11:07:00 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: update TCPCMD
To: tcp-group@ucsd.edu

I have placed a new tcpcmd.c at wg7j.ece.orst.edu's incoming. It
addresses a few problems when using repeat.

1. The 'tcp stat' - 't s' command listed all sockets even if they
   were in listen state. When you have many servers going at once
   as I do the screen can get very long - also when using repeat
   a display CANNOT obviously be longer than a screen.

With the new code the 't s' command now does NOT display Listen sockets.
Use 't s a' to display ALL sockets as usual.

2. The 'tcp view bytes|timers', 't v t', 't v b' - command did not display
   a banner if not sockets were displayed. This was fine for the normal
   display but for repeat if no sockets were active nothing displays.
   Also if just one socket was active and went away it stayed until
   another became active.

In the new code a banner always displays.

I find the repeat code gives NOS a new dimension. It is really neat
to see things change dynamically. Many thanks to Phil for the idea.
On my 386sx switch at home I run a mono card, which is typically
slower than current VGA. I find that the mono screen persistence
couple with a repeat update of 500 (1/2 sec) works very nicely.

Doug

------------------------------

Date: Fri, 8 Jan 93 17:18:30 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: V40 machine
To: n8fow@wsu.n8fow.ampr.org

> Date: Fri, 08 Jan 93 05:14:43 UTC
> Message-Id: <5017@wsu.n8fow.ampr.org>
> From: n8fow@wsu.n8fow.ampr.org
>
>      Actually I have a laptop here that has a V40 for it's CPU. There are
> a couple plug-in boards for the PC that have V40 processors. The MIO board
> is one and I believe it can run NOS for a standalone site.  I didn't enter
> the cpu-id code, maybe someone can just post it somewhere to save time
> (too busy with Borland C++ to remember debug :-)   and I can run it on
> the V40 machine and see what it says.  I ran several programs about the

I have rewritten Mike's program in C (tried to compile it using BC 3.0,
TC++ 1.01, MSC 6.0, TC 2.0, TC 1.5 - was working OK for every compiler).
Here it is - run it and post results to Mike Bilow, <mikebw@ids.net>

char cpuid[]={
 0x52,0x33,0xD2,0x9C,0x58,0x80,0xE4,0x0F,0x50,0x9D,0x9C,
 0x58,0x80,0xE4,0xF0,0x80,0xFC,0xF0,0x74,0x12,0xFE,0xC2,
 0x9C,0x58,0x80,0xCC,0xF0,0x50,0x9D,0x9C,0x58,0x80,0xE4,
 0xF0,0x74,0x02,0xFE,0xC2,0xFE,0xC2,0x8B,0xC2,0x5A,0xCB},
 *cpuname[]={"8088/8086/V20/V30\n","80286\n","80386/80486\n"};

main()
{
  int cpu,(far *CpuId)()=(int (far *)())cpuid;
  cpu=(*CpuId)();
  printf("\nProcessor detected: %s",cpuname[cpu-1]);
}

73's, JT

------------------------------

Date: Fri, 08 Jan 93 20:53:05 CET
From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
Subject: WHAT IS SMACK ?
To: TCP-GROUP <TCP-GROUP@ucsd.edu>,

The subject line says it all.
it seems to be in new netrom type or tnc type boxes
some talk about it has been seen in Germany for past 6 months
but i have never gotten a sensible reply for any one.
Any Idears? Please
Barry

------------------------------

Date: Fri, 08 Jan 93 14:54:14 CET
From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
Subject: WNOS-Group server Back.
To: Packet Radio Digest <packet-radio@ucsd.edu>,

Hello.
The Listserv@esoc.bitnet now again has its group server running again
If you wish to be informed about WNOS specific bugs and software fixes
then send a mail to the listserv@esoc.bitnet and use the SIGNON WNOS-GRP
or simply help will get son info on how to do it.
Thanks Barry List-Owner.
New versions of WNOS - 5 out in the comming months.

------------------------------

Date: Fri, 8 Jan 93 23:12:26 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: xspawn
To: tcp-group@ucsd.edu



------------------------------

Date: 08 Jan 1993 12:06:31 -0500 (EST)
From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
Subject: XSPAWN - once more
To: tcp-group@ucsd.edu

After some more testing, I suggest changing the two lines in yesterday's
XSPAWN fix in pc.c from

     addvect (......, IRET)

to

     addvect (......, CURRENT)

Seems to work better!

As for packet driver fixes.... Since I am not using any packet driver code
I will pass the torch to others                 ;-)

 
73 from Brian A. Lantz      KO4KS@KO4KS.#TPAFL.FL.USA.NA    3100813105
                  Internet: brianlantz@delphi.com
                   Amprnet: ko4ks@ko4ks.ampr.org         [44.98.0.167]

------------------------------

End of TCP-Group Digest V93 #9
******************************
******************************
